-
Notifications
You must be signed in to change notification settings - Fork 14.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use git submodules for (securely) using third party Github Actions. #13514
Conversation
See https://github.com/astronomer/airflow/pull/1171/files for what the review process looks like for when a submodule is updated in a PR. (I downgraded that submodule to v1_2 in that draft PR) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, better than maintaining a separate repo for each action
678ba95
to
087d0a0
Compare
Could someone please double check my changes are right, in particular the build-images one -- I think it should be running the actions from the main branch, not the PR branch. |
You can check it yourself, just push to your fork as main branch (you have to have github actions enabled). I will do it now as well, but this is the easiest one for you to check it. |
Ah cool yes, I'll check that. |
I do not see the code from |
Hmm, what do I have to do to turn actions on for my fork? I don't see an option to enable/disable actions in my settings. Must be missing it. Oh found it - the workflow was manually disabled |
Yeah -for adding a new submodule it shows that. Updating a submodule shows the full/better view ashb#3 |
Are you sure it works from the forks? I suspect it is only for PRs in the same repo. |
I will push it as a branch to 'apache/airflow' and see if it looks better. We can have a rule that only committers make changes to actions and only do it via internal PR if we find that this is the case |
Cross repo PR that updates a sub-module ^^ |
Yep. just tested it :). All Good ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Build passed in my fork:
https://github.com/potiuk/airflow/actions/runs/468787325
And CI builds are about to pass as well:
https://github.com/potiuk/airflow/actions/runs/468787281
The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest master at your convenience, or amend the last commit of the PR, and push it with --force-with-lease. |
Rather than having to mirror all the repos we can instead use git submodules to pull in the third party actions we want to use - with recent(ish) changes in review for submodules on GitHub we still get the same "review/audit" visibility for changes, but this way we don't have to either "pollute" our repo with the actions code, nor do we have to maintain a fork of the third party action.
087d0a0
to
b7423f3
Compare
The most recent submodule change for actions apache#13514 was done in parallel to Optimising worklfows in apache#13562 and the job added in the apache#13562 still uses non-submodule version of check action. Also few checkout steps missed: 'submodules: recursive' input This PR fixes that and all 3rd-party actions now are used from submodule.
The most recent submodule change for actions #13514 was done in parallel to Optimising worklfows in #13562 and the job added in the #13562 still uses non-submodule version of check action. Also few checkout steps missed: 'submodules: recursive' input This PR fixes that and all 3rd-party actions now are used from submodule.
Rather than having to mirror all the repos we can instead use git submodules to pull in the third party actions we want to use - with recent(ish) changes in review for submodules on GitHub we still get the same "review/audit" visibility for changes, but this way we don't have to either "pollute" our repo with the actions code, nor do we have to maintain a fork of the third party action. (cherry picked from commit f115983)
Rather than having to mirror all the repos we can instead use git submodules to pull in the third party actions we want to use - with recent(ish) changes in review for submodules on GitHub we still get the same "review/audit" visibility for changes, but this way we don't have to either "pollute" our repo with the actions code, nor do we have to maintain a fork of the third party action. (cherry picked from commit f115983)
The most recent submodule change for actions #13514 was done in parallel to Optimising worklfows in #13562 and the job added in the #13562 still uses non-submodule version of check action. Also few checkout steps missed: 'submodules: recursive' input This PR fixes that and all 3rd-party actions now are used from submodule. (cherry picked from commit eb40eea)
Rather than having to mirror all the repos we can instead use git submodules to pull in the third party actions we want to use - with recent(ish) changes in review for submodules on GitHub we still get the same "review/audit" visibility for changes, but this way we don't have to either "pollute" our repo with the actions code, nor do we have to maintain a fork of the third party action. (cherry picked from commit f115983)
Rather than having to mirror all the repos we can instead use git submodules to pull in the third party actions we want to use - with recent(ish) changes in review for submodules on GitHub we still get the same "review/audit" visibility for changes, but this way we don't have to either "pollute" our repo with the actions code, nor do we have to maintain a fork of the third party action. (cherry picked from commit f115983)
Rather than having to mirror all the repos we can instead use git submodules to pull in the third party actions we want to use - with recent(ish) changes in review for submodules on GitHub we still get the same "review/audit" visibility for changes, but this way we don't have to either "pollute" our repo with the actions code, nor do we have to maintain a fork of the third party action. (cherry picked from commit f115983)
Rather than having to mirror all the repos we can instead use git submodules to pull in the third party actions we want to use - with recent(ish) changes in review for submodules on GitHub we still get the same "review/audit" visibility for changes, but this way we don't have to either "pollute" our repo with the actions code, nor do we have to maintain a fork of the third party action. (cherry picked from commit f115983) (cherry picked from commit eddd632)
The most recent submodule change for actions apache#13514 was done in parallel to Optimising worklfows in apache#13562 and the job added in the apache#13562 still uses non-submodule version of check action. Also few checkout steps missed: 'submodules: recursive' input This PR fixes that and all 3rd-party actions now are used from submodule. (cherry picked from commit eb40eea) (cherry picked from commit c8895bd)
@ashb How did this idea come about? This is the only project I've come across that partitions their third-party Actions in such a manner. Was there any prior attempts at this anywhere else? |
This was triggered by a potential supply-chain attack that can be issued when you are integrating GitHub Actions via tag or branch. Submodule solution automatically implements all the recommendations described by Github Actions here https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions , including the fact that it is very easy to review any PRs where actions are updated (such PR will allow to review the changes in the action as submodules are nicely integrated in GitHub PR review process). You can read summary of the GitHub Action status here - and all context and explanations for recommendations we came up with and proposed to other ASF projects: https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status |
@RA80533 this brought on a setting by Apache Software Foundation Infra and security teams changed on our GitHub org - they only allow Actions from official GitHub, or ASF repos. This is to somewhat defend against "supply chain" attacks where a project uses some random action which is then updated to exfil creds etc. |
About prior art - not that I am aware of it but also Apache beam started using it after the discussion https://github.com/apache/beam/blob/master/.gitmodules |
My change is the fix and improvement for github action which labels approved PRs (introduced in this [PR](#6239)). It is inspired by solution introduced and tested in [Apache Airflow](https://github.com/apache/airflow) (thanks @potiuk @ashb 🚀 ) Corresponding Apache Airflow workflows on which I based this PR: - https://github.com/apache/airflow/blob/main/.github/workflows/label_when_reviewed.yml - https://github.com/apache/airflow/blob/main/.github/workflows/label_when_reviewed_workflow_run.yml Problems which were solved in this PR: - **Permissions**. @morningman opened a related bug: [[Help] Error: Resource not accessible by integration](TobKed/label-when-approved-action#7). It is related to limited permissions of workflows being triggered by `pull_request_review` (`GITHUB_TOKEN` has read-only permissions). More information about it you can find in the article: [Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). TL;DR: On pull request review event (`on: pull_request_review` ) "dummy" workflow `Label when reviewed` triggers another workflow `Label when approved workflow run` which has sufficient permissions (`on: workflow_run: workflows: ["Label when reviewed"]`). - **Safe use of 3rd-party Github Actions by using submodules pattern.** It is decribed in: https://cwiki.apache.org/confluence/display/BUILDS/GitHub+Actions+status > NEVER use 3rd-party actions directly in your workflows - use the "submodule" pattern. This pattern is successfully used by projects like: - [Apache Airflow](https://github.com/apache/airflow) ([PR](apache/airflow#13514)) - [Apache Beam](https://github.com/apache/beam) ([PR](apache/beam#13736)) - [Apache Superset](https://github.com/apache/superset) ([PR](apache/superset#12709))
This approach gives us the ability to keep track of the actions we use, doesn't fall foul of the "no third party actions" org-wide setting, and still gives us "audit-by-default" -- any change to the commit of a submodule would need a PR and GitHub handles this quite nicely on the PR review.
Note: I an still generally against submodules as they are difficult to use, but since this is only for CI and everyone* else can checkout the repo and not have to care that the submodules exist I think it the right tool for this use case.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.